(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



CORRECTED VERSION 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
28 February 2002 (28.02.2002) 




(10) International Publication Number 

PCX wo 02/017080 A2 



(51) International Patent Classification^: G06F 1 1/34 

(21) International Application Number: PCT/USOl/26152 

(22) International FiUng Date: 22 August 2001 (22.08.2001) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

60/226,816 
09/933,540 



22 August 2000 (22.08.2000) US 
20 August 2001 (20.08.2001) US 



(71) Applicant: ISOGON CORPORATION [US/US]; 330 
Seventh Avenue, New Yoric, NY 10001 (US). 

(72) Inventor: BARRITZ, Robert; Isogon Corporation, 330 
Seventh Avenue, New York, NY 10001 (US), 



(74) Agents: MOSKOWITZ, Max et ah; Ostrolenk, Faber, 
Gerb & Soffen, LLP, 1 1 80 Avenue of the Americas, New 
York, NY 10036 (US). 

(81) Designated States (national)\ AE, AG. AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, H. GB, GD, GE, GH, 
GM, HR, HU, ID, TL, IN, IS, JP, KE, KG, KP, KR, KZ, LC. 
LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, PH, PL, PT, RO, RU, SO, SE, SG, SI, 
SK, SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, 
ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD. RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 

[Continued on next page] 



(54) Title: METHOD AND SYSTEM FOR DETERMINING THE USE AND NON-USE OF SOFTWARE PROGRAMS 



< 
QO 



o 
O 



■^F ^ START ^ 



Construct table ot _ 
sottuware ptoducta 
Bocordlno to name and 
tibrery from software 
inventory 



70 



•72 



74 



Read next softHrare 
pnxJud nam«ftibraiy 
from usaga data file 



76 




Uit complated? J>^— Yes — ►] Report Resutts 



7^ 



78 



No 



Locate in the software 
inventory, the software 
product hsve ttiit name 
and litirary — 



80 



-82 



<r Found? >> NO — ^ 



86 



Report Protlua not 
m inwemory 



Yes 

4 

Ramova from . 
tat>le or (tag as 
used 



■88 



(57) Abstract: A method and system for auditing software systems by monitor- 
ing the use and non-use of software programs in a computer. An operating system 
of the computer controls execution of software products through the invocation 
of respective load modules thereof. A monitor is periodically triggered to collect 
load module execution information and a correlator correlates load module execu- 
tion information with data that associates load module names with corresponding 
software products and develops a list of products executed in the computer over 
the course of a given time period. Alternatively, rather than ojjerating periodi- 
cally, the monitor collects load module execution information at the end of and 
by being triggered by computer processes controlled by the operating system. As 
a further alternative, the monitoring of the execution of software products is de- 
tected by monitoring inputs and/or outputs to specific files or datasets, reflecting 
uniquely the use of corresponding software products. TTie invention also provides 
the ability to determine the load libraries and search order for load modules being 
executed or called by the operating system. 
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METHOD AND SYSTEM FOR DETERMINING 
THE USE AND NON-USE OF SOFTWARE PROGRAMS 

RELATED APPLICATION 

This Application claims priority and is entitled 
5 to the filing date of U.S. Provisional Application 

Serial No. 60/226,816 filed August 22, 2000, and 
entitled "METHOD AND SYSTEM FOR DETERMINING THE USE 
AND NON-USE OF SOFTWARE PROGRAMS," the contents of 
which are incorporated by reference herein. 

10 BACKGROUND OF THE INVENTION 

The present invention relates to software 
auditing systems and, more particularly, the invention 
concerns a method and system for monitoring the use 
and non-use of software programs . 

15 Licensed software products, such as those from 

IBM, Computer Associates or Microsoft, are typically 
composed of a number of discrete executable 
components: exe-files, batch files, JCL, etc, herein 
collectively referred to as modules. A typical 

20 mainframe computer might have 50 0 products, composed 

of 500,000 modules on 3,000 libraries, often with many 
of the products duplicated on a number of libraries. 
While many software products are installed in default 
libraries specified by the vendor, some installations 

25 choose to link the more commonly used products into 

the system libraries. 

Prior Isogon patents have described techniques 
for performing software auditing, including the steps 
of Surveying (scanning all hard^drives or disk storage 

30 for modules) , Identification (deciding, for each 
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module on each library, what software product it 
belongs to) and Monitoring (intercepting and recording 
all module executions) . As described in those patents, 
and as practiced by Isogon's software auditing 
5 product, SoftAudit, the steps of Surveying, 

Identification, and Monitoring are both interrelated 
and separate processes . 

The SoftAudit Monitor is also described in the 
present Assignee's issued United States Patent No, 

10 5,590,056, the contents of which are incorporated by 

reference herein. The SoftAudit Monitor collects 
usage data for (virtually) every load module executed 
within the system (image, LPAR) . This usage data is 
correlated to survey and identification data to 

15 ultimately determine and report which software 

products, and the libraries in which they are 
installed, have and have not been used. 

For the MVS and OS/390 operating systems, it does 
this by intercepting the LOAD, LINK, ATTACH, and XCTL 

20 system functions. Whenever such a function is invoked, 

the Monitor creates an entry in a memory table which 
relates the module usage to the job/ job step/started 
task/TSO session (hereinafter, process) for which the 
module was loaded. Eventually, the usage data is 

25 written to external media (either when the memory 

buffer needs to be reclaimed, or on an hourly basis) 
and subsequently correlated with other data as 
previously described. 

Due to the high number of executing modules, both 

30 the volume of data recorded and the processing time 

used can .become excessive. In other situations, such 
as with different operating systems, intercepting 
system calls may not be practical or would greatly 
impact system response times. 
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SUMMARY OF THE INVENTION 

The term module is meant to include executable 
software programs, executable script files such as 
Unix shell scripts, and interpreted programming 
5 languages such as Java and Basic. 

It is an object of the present invention to 
provide- an improved method of software auditing 
whereby the execution of software modules can be 
determined in a manner that does not overly burden 
10 system resources, and that this execution information 

can be correlated with other information to determine 
which products have been executed - 

It is another object of the present invention to 
provide a method whereby the execution of software 
15 products can be deteormined according to their usage of 

the file system. 

It is a further object of the present invention 
to provide a method whereby the non-use of software 
products can be detected - 
20 It is yet another object of the present invention 

to provide a method whereby the load library from 
which a module was loaded can be determined. 

The foregoing and other objects of the invention 
are essentially realized by a method and system in 
25 which the approach to auditing is designed to obtain 

data for fewer than all of the load modules that 
execute on the system. Preferably, the system employs 
intelligence to monitor activities and/or select 
information which best approximates the total number 
30 of software products that are executed in the system 

over selected time periods. 

Other features and advantages of the present 
invention will become apparent from the following 
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description of the invention which refers to the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a prior art software monitoring and 
5 surveying system. • 

Figure 2 is a sample output of the invention. 
Figure 2A is another sample output of the invention . 
Figure 3 is a sample output of the invention. 
Figure 4 is a first flow chart of the invention. 
10 Figure 5 is a second flow chart of the invention. 

Figure 6 displays an output of the invention. 
Figure 7 is a third flow chart of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Reduced Overhead Determination of Software Product 
15 Usage 

In one embodiment, the Monitor is implemented as a 
backgroiind process that periodically samples system data 
to determine which processes are active. As is well known 
in the computer art, operating systems control and define 

20- segments of program executions into "processes," job 

steps, etc. For some operating systems such as Unix, a 
background process can execute as a free running program 
(called a daemon) or be scheduled on a time basis using 
the ''crontab" facility. In either case, the Monitor 

25 (described below) is able to sample the processing state 

of the system - 

With reference to prior art Figure 1, a conventional 
computer system 10 is shown in block form. As is 
conventional, the computer system 10 includes an 
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operating system 24 and may include an automatic job 
scheduler 32. As is also conventional, the computer 
system 10 connects the peripheral devices, examples of 
which are shown in Figure 1 and may include one or more 
5 storage devices, for example, 14, 16 and 18, interactive 

user terminals 26, 28 and 30, and a batch job reader 34. 
Not all of these peripheral devices are required to be 
present, and varying computer systems will have differing 
peripherals. The operating system 24 may contain a 

10 centralized handler 44 for the processing of service 

requests. Where this is the case, services 4 6a-46e are 
usually also provided. 

Generally, the present invention provides a system 
for monitoring, tracking and controlling the use of 

15 software products and the modules that comprise them. 

Instrumental to the operation of the invention are a 
monitor 22 shown in the fo3rm of a monitoring program, a 
surveyor 12 in the form of a surveying program, having an 
associate directory 12a and a module reader 12b which are 

20 operable in conjunction with a system configuration log 

66 and a knowledge base 20. A further information log 62 
communicates with the monitor 22 as well as with a 
reporting program 60 which uses an identifier component 
60A and a reporter component 60B to generate reports 64 . 

25 Conventionally, the computer system 10 also has an 

on-line display 68. 

Thus, for example, when the Monitor 22 receives 
control under Unix, it can use system commands such as 
"ps" or the "kvm__getprocs" system call to take a snapshot 

30 of the current state of all active processes including 

the user name, the time they were started, how much CPU 
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time has been used, and the directory (pathname) from 
which it is installed. Figure 2 presents a sample of how 
the process state might appear in a snapshot 3 6 taken at 
3:00 PM by the Monitor process (/etc/monitor), as 
5 indicated at 38, 

In processing this data, the Monitor produces a 
table of executing modules and their pathnames. In the 
example of Figure 2, the modules emacs, grep, less, man, 
monitor, netscape, ps, sh, telnet, tsch and vJdbd are 

10 identified. If, for example., the Monitor takes a snapshot 
at 5 minute inteirvals, then the only new modules to be 
executed since 2:55 PM are the grep and ps system 
programs, and the Monitoring program - monitor. As the 
system command ps is used by monitor, the Monitor 

15 typically ignores itself and any modules it might use. 

System programs, such as those that comprise the 
operating system itself, are typically not of interest. 
Thus, if filtering of known system programs is employed 
by the Monitor, it is likely that since 10:00 AM only 

20 programs such as netscape would be identified. 

In this example, the method of extracting module 
information from each line of the process state 
encompasses the following steps: 

1. Extract the time at which the process started. 

25 2 . Did the process start after the last snapshot 

was taken? If not, ignore this process and proceed to the 
next line. 

3 . Extract the pathname of the process and the 
module name, in particular. For example, the process 
30 "/usr/local /netscape" is located in the directory 

"/■^sr/local" and has a module name of '"netscape." 



wo 02/17080 



PCT/USOl/26152 



4. Add the module name and, optionally other 
process related information to the module usage table 
such as the directoiry, start time, process ID, etc. 

5. Optionally, adapt the scheduling of snapshots 
5 by detecting periods of high and low activity. 

This module usage data is equivalent to that 
produced by software asset management products (such as 
SoftAudit, which gathers usage data by intercepting 
system functions) and can instead be used by such 

10 products to provide usage statistics and identify the 
software products they belong to. 

Optionally, the Monitor adapts the frequency with 
which it takes a snapshot of the system processing state. 
It is important that the Monitor detect as many executing 

15 modules as possible. However, during periods of high 

processing activity a large number of processes may begin 
and end between snapshots. While the Monitor cannot go 
back in time to capture what has already been lost, it 
may adapt its schedule in accordance to process activity. 

20 In comparing process ID (pid) data in a snapshot 

from one taken immediately prior, the Monitor determines 
how many processes have begun and ended in the 
intervening period, in other words, have been missed. 
Process IDs under Unix, and many other operating systems, 

25 are incremented for each new process that is executed. 

Thus if the Monitor subtracts the highest pid found in a 
prior snapshot (H) from the current ' pid of the Monitor 
itself (M) , the result is an indicator of how many 
processes have been executed in the intervening time 

30 period. The Monitor then proceeds to take a count of all 

processes that have begun since the prior snapshot and 
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are still executing (E) . Subtracting this number from the 
number of processes that have been executed is an 
indicator of how many have been missed. In other words: 
Number of Missed Modules = M - H - E • 
5 If this number is high, the Monitor can increase the 

frequency of its snapshots and, if the number is low, 
decrease the frequency to an acceptable level. 
Furthermore, the Monitor may examine a history of system 
activity, either from system logs or data maintained by 

10 the Monitor itself, to ascertain if these levels are 

normal or otherwise prior to adjusting its sampling rate. 

For example, referring to the snapshot at 3:00PM 
(Figure 2) and a second snapshot 40 taken 5 minutes later 
(Figure 2A) , one will note that the highest pid, H, was 

15 3692 in the earlier snapshot 36 and that M=3713 at 42 is 

the pid of the Monitor in the current snapshot. This 
means that 21 processes have run in the intervening 5 
minutes. Comparing the two snapshots, only E=2 new 
processes (3586 and 3709) are detected, thus, 19 have 

20 been missed. Considering that nearly 90% of the 

intervening processes have been missed, the Monitor may 
adjust its sampling rate, or, after examining the system 
activity history determine that 21 processes in 5 minutes 
is considered low at this time of day and that no change 

25 in sampling rate is deemed necessary. 

In another embodiment, the present invention deduces 
which software modules are used in a process by 
extracting load module information produced directly by 
the operating system while processing access requests 

30 such as LOAD, LINK, etc. for the process. 
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As a process executes, it makes access requests for 
modules. The operating system, in processing those 
requests, may create a table (or catalog) and/or library 
of these load modules. For each required module, the 
5 operating system makes an entry in the load module table 

(LMT) that may contain among other things, the name of 
the module, other process specific information such as 
process ID, etc., and perhaps, some attributes of the 
module such as its size, date of creation, and so on. 

10 In this embodiment, the Monitor function is 

implemented to execute every time the end of a process is 
reached. This does not have to be the same time as when 
the process completes execution but rather at some time 
after which the operating system updates the LMT. MVS and 

15 OS/390 provide such facilities to initiate the Monitor in 

the form of an exit routine, hereinafter, a Monitor Exit. 
Alternatively, the Monitor Exit may be established to 
receive control when a function (such as FILE CLOSE) , is 
invariably executed at or near the end of a process. 

20 When the Monitor Exit is reached, the Monitor is 

activated and proceeds to read the LMT from which it 
determines the names of modules that have been cataloged 
and loaded for that process. For each module found in the 
LMT, the Monitor creates a record in a module usage table 

25 that contains the module name. Optionally, the Monitor 

also stores in the module .usage table any other 
characteristics that the operating system might provide 
such as the module size, date of last change, other 
process information such as process ID, current time and 

30 date, etc. 
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Optionally, usage data is accumulated across 
processes. For example, when the next job step (or the 
job) completes, the Monitor Exit routine is once again 
activated. The LMT is again read and any new module 
5 entries are added to the module usage table. Names of 

modules already found in the table for the current job 
are ignored as they have already been identified as 
having been used for the current process. When the job is 
completed, the Monitor stores (appends) the module usage 

10 data in a file for further processing to identify the 

software products used, by such products as SoftAudit, in 
order to provide usage statistics, etc. 

An additional facility of the present invention uses 
the module usage data to identify the software products 

15 used- 

The method of determining product usage according to 
module usage data is performed in one of the following 
two ways : 

1. Identify the names of all software products 

20 used by correlating module usage data using the Knowledge 

Base (KB) 2.0 that associates the names of modules to the 
software products they comprise. 

2 . Correlate the module usage data with an 
inventory of software products that itself has been 

25. correlated to the Knowledge Base 20. 

Identification of Product Usage According to File Name 

Generally speaking, virtually every software product 
performs some type of input/output and, in most cases, to 
specific files or datasets. For example, every time a 
30 software product is executed, i.e., one or more of the 
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component modules is executed, it will read from and/or 
write to files such as a configuration files, temporary 
data files, output data files, etc. having specific 
names . 

5 In some circumstances, different software products 

from the same vendor will share certain files which, in 
turn, are still unique to that vendor. 

For example, some of the files "required" by- 
products A and B on MVS might include: 
10 o PRODUCTA.PRODDATA - product A database 

o PRODUCTA . PREFS - product A preference file 
o PRODUCTS . USERDATA - product B user data file 
o PRODUCTB . INIT - product B initialization file 
For operating systems such as Unix, these files 
15 might appear as: 

o /usr /local /product A/proddat a - product A database 
o /usr/local/productA/pref s - product A preference 
file 

o /usr/local/productB/userdata - product B user data 
20 file 

o /usr/local/productB/init - product B initialization 
file 

The first two files are unique to the family of 
software for product A, hence, the detection of any one 
25 of these files by a monitoring program is sufficient to 

identify the A product irrespective of the individual 
program in the product A module suite that actually 
performed the I/O. Similarly for product B. 

The method of determining product usage according to 
30 file usage data is performed in the following steps: 
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1. Monitoring - determine the names of all files 
used by a process; 

2. Identify the names of all software products 
used by correlating file name usage data using a 

5 Knowledge Base that associates file names to software 

products; 

3. Optionally, determine the modules comprising 
each software product used. 

1. Monitoring File Usage 

10 In one embodiment, the Monitor is implemented as a 

background process that periodically takes a snapshot of 
system data to determine which files are currently in 
use, optionally filtering out those known to be temporary 
files. For Unix, the monitoring process can execute as a 

15 daemon process or be scheduled on a time basis using the 

''crontab" facility. In either case, the Monitor is able 
to take a snapshot of the current state of the files in 
use, optionally adapting its schedule according to system 
activity. 

20 For example, when the Monitor receives control under 

Unix, it can use- commands such as *'f stat" or the 
"kvm_files" system call to sample the state and certain 
characteristics of all active files. Such information 
includes the user name, name of the process and its 

25 process ID, and the pathname (name and directory) of the 
file. Figure 3 is a sample 48 of how the file state might 
appear in one snapshot . 

In processing and filtering this data, the Monitor 
produces a table of open files for the processes emacs, 

30 man, netscape, and telnet. The filter has removed 
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temporary files such as those having pathnames beginning 
with "/usr/tmp/tempf ile" and other "known" system 
parameter files such as /usr/local/inf o. 

Note that the command name (e.g., emacs) of the 
5 process using that file can also be used by the Monitor 

to filter out file usage by system programs. For example, 
if a required configuration file for software product A 
is being edited by the user, one might conclude that 
simply on the basis of file usage that product A was 
10 executing when in fact it had not. Filtering out this 
occurrence eliminates this false conclusion. 

An entry is created in -a file usage table for each 
new file name found for the same process ID. Other 
process information such as process ID, and optionally, 
15 command name, the current time and date, etc. are also 

saved in the file usage data record. 

Optionally, the Monitor adjusts its sampling rate in 
a manner similar to that described in an earlier 
embodiment . 

20 In another embodiment, the Monitor f\mction is 

implemented as an intercept placed in either or both of 
the file OPEN and CLOSE system functions. 

Whenever activated, the Monitor determines the name 
of file that is being used by the current process. An 

25 entry is created in a file usage table for each new file 
name found for the current process. Other process 
information such as process ID, and optionally, the 
current time and date, etc. are also saved in the file 
usage data record. 

30 If, in one instance, the Monitor determines that the 

name of a file is already in the table and has the same 
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process ID, the instance is ignored and no entries are 
made in the file usage table . 

Alternatively, the Monitor function, operating in a 
manner such as a Monitor Exit, reads the JCL data 
5 structures of the current job or the in-storage data 

created therefrom by the operating system, such as the 
Task Input Output Table (TIOT)-, to obtain the dataset 
names specified by various DD (Data Definition) 
statements in the job and stores those results in the 

10 file usage table. 

In yet another alternative, the Monitor, perhaps 
operating as a batch process, reads the Unix system 
accounting logs or MVS and OS/390 System Management 
Facility (SMF) data file at some point in time, after the 

15 completion of the process itself, to determine the file 

names and load libraries used on a job-by- job and 
process-by-process basis and stores these results in the 
file usage table. 

2 . Identifying Software Product Usage 
20 ' The File Knowledge Base (FKB) is- a database of 

records which associates file names to the software 
products which use them. In addition to the files name, 
the FKB might contain other attributes such as: 

o Flags indicating if the file is used uniquely 
25 or shared among vendor products; 

o Number of file matches ("hits") required for 

correlation with a product; 
o File type such as text, binary, database, etc.; 
« Always used or used sporadically; 
30 p File size, creation date, etc.; 
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o Embedded strings of text or data; 
o Etc. 

Using various heuristics and perhaps some of these 
attributes, an Identifier facility 60A takes the file 
5 names determined by the Monitor and correlates these 

against those in the FKB to deduce a list of software 
products which have been executed and stores that 
information in a product usage table. For example, if the 
Identifier determines that a process uses 10 files of 
10 which 9 hits are found for product A and only 1 hit for 
product B, then product A is the most probable choice. 

3 . Determine the Modules Comprising Each Software 
Product Used 

As another feature of the current embodiment, the 
15 Identifier determines the modules which comprise each 

software product that has executed and stores that 

information in a module usage table. 

For each software product identified in the previous 

step as having been used, the present invention retrieves 
20 the list of modules that comprise the product from a 

knowledge base (KB) that correlates module names to 

software products and vice versa. This information is 

stored in a separate table, file or as part of the module 

usage table . 

25 Such information may be used by another embodiment 

of the present invention to determine the load library 
from which each software product executes from. 
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Detennination of Unused Software Products 

In another embodiment, the present invention 
determines which software products have not been used on 
a computer system. 
5 The general procedure is as follows: 

1. Determine the software products used; 

2. Dete2rmine the inventory of software products on 
the computer system; 

3 . Compare the list of products used to the 

10 inventory of such products to produ.ce a list of 

unused products. 
Typically, the method for determining software 
products that are used involves the steps of determining 
the modules that are used (as described above, or in 

15 Isogon's earlier patents) and correlating those modules 

against a module-to-product knowledge base (KB) . 
Optionally, the library on which the product resided is 
also determined. 

An inventory of software products is performed 

20 similarly, however, the module and library data is 

obtained by performing a survey of all storage devices. 
The modules found are correlated against the module KB to 
identify the software product name. The same product may 
be found to reside on multiple libraries for reasons such 

25 as keeping backup copies. Such techniques are used by 

software asset management products such as SoftAudit. 

At some point in time, after sufficient product 
usage data has been accumulated or obtained from other 
sources, the present invention determines which software 

30 products have not been used (Figure 4) . 
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The self-explanatory process steps shown in Figure 4 
listed below are as follows: 



1. Start of process - step 70; 

2 - Construct table of software products according 
5 to name and library from software inventory; - 

step 72 ; 

3 . Read next software product name/ library from 

usage data file - step 74; 

4 . Determine whether the list has been completed - 
10 step 76; 

5. If list has been conpleted, report results - 
step 78; 

6. Report results and end ^ steps 78, 80; 

7- If a list has not been completed, locate in the 
15 software inventory, the software products that 

have that name and library - step 82; 
8 , Determine whether any software products were 

found - step 84; 
9. If none found, report products not in inventory 
20 (step 86) and return to step 74; 



10. If yes, remove from table or flag as used - 

step 88 - and return to step 74. 
In one embodiment, a table (list) of all software 
products and the libraries they are installed on is made 
25 using inventory data. For each software product /library 

entry found in the usage file, the corresponding entry in 
the inventory list is either removed or flagged as having 
been used. (If a corresponding entry is not found in the 
inventory list for an entry in the usage table, it is 
30 probably due to survey data that is out of date and is 

optionally reported to the user.) After all usage data 
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entries have been processed, the resulting taile reflects 
all software product /library combinations which have not 
been used. 

Optionally, the present invention flags or removes 
5 all entries in the inventory list that correspond to a 

used software product. The resulting table reflects all 
software products that have not been used irrespective of 
the library or libraries they reside upon. 

Determination of the Library a Module was Loaded From 

10 In another embodiment, the present invention 

determines the load library from which each module 
executed has been loaded and stores that information in a 
module usage table. 

The general procedure involves the following steps: 

15 1. Obtain a list of the modules that have been 

used by a particular process. 

2 . Determine the load libraries and their search 
order used by the process. 

3 . Using the search order determined in the 

20 previous step, search the load libraries for the first 

library containing the same modules that best matches the 
list of modules used. 

Other embodiments of the present invention provide a 
Monitor function that determines a list of modules used. 

25 This list is kept in a module usage table that optionally 

contains additional process information. Alternatively, 
module usage data from other usage monitoring products 
such as SoftAudit can be imported into the present 
invention and incorporated into the module usage table in 

30 place of or in addition to any other usage data. 
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The next steps of determining the correct load 
libraries in their appropriate search order and further 
determining which libraries the modules executed from can 
be embodied in any or all of the following ways: 
5 o As a concurrent process wherein module usage data 

and load libraries selection data are both obtained 
by the Monitor and library usage is determined at 
the same time, 
o As separate processes wherein module usage data, on 
10 the one hand, and load library data, on the other, 

are obtained from separate sources and processed to 
determine load library usage. For example, module 
usage data is obtained using the previously 
described method of determining software product 
15 usage according to file usage and library selection 

data is determined from the SMF data file. 
o As separate processes wherein one of the module 

usage data or library selection data is obtained by 
the Monitor and the other obtained from a separate 
20 source and processed to determine load library 

usage. For example, module usage data is obtained- 
from a monitoring product such as SoftAudit and 
library usage is determined from the Monitor 
function described below. 
25 The following description of the present invention 

is specific to a concurrent process on a mainframe 
operating system such as MVS, however, the method is 
equally applicable to other operating systems and other 
embodiments previously described. 
30 For mainframe operating systems such as MVS, as the 

JCL for the job is interpreted and subsequently executed 
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(i.e., the job and its individual job steps are 
processed) , the operating system, following a prescribed 
search order, determines which load libraries are to be 
searched for the modules subsequently accessed via system 
5 calls such as LOAD, LINK, etc. 

The JCL interpreter is capable of defining "generic" 
load libraries to be used within a specific scope and 
searched in a specific order. If the user so desires, he 
can define a library of modules to be known generically 

10 throughout his entire job as JOBLIB, Similarly, the user 
has the option to define a library of modules that 
changes with each step in the job. This is known as 
STEPLIB. The operating system saves each of these JOBLIB 
and STEPLIB definitions in a list (load library list) . 

15 Lastly, system libraries, such as SYSl.LINKLIB or 

SYSl .USERLIB, and the modules they contain are readily 
available to all job processes. For this reason, some 
computer installations choose to install commonly used 
software products in these libraries. 

20 Referring to Figure 5, when a module is accessed via 

LOAD, etc., the operating system searches the load 
libraries for that module in a specific order of 
precedence - the current STEPLIB first, then JOBLIB, 
followed by the system libraries SYSl.LINKLIB, etc. If 

25 the module is not found in STEPLIB or it is not defined, 

JOBLIB is searched. If not found in JOBLIB, or a JOBLIB 
is not defined, the operating system proceeds to search 
in turn each of the system libraries. 

For example, the fragment 150 of JCL in Figure 6 

30 demonstrates the use of software product libraries in 

JOBLIB and STEPLIB statements, as well as the' search 
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procedure for some product specific programs {RPORTA for 
product A and SORTB for product B) and a system program 
(FIND) . 

In this example, the JOBLIB DD statement specifies 
5 that the programs for software product A in library 

PRODUCTA.LOADLIB be known and available throughout the 
job. In STEPl, the system is directed to use the program 
"FIND", which in this example is located in one of the 
system libraries. As there is no STEPLIB for this job 

10 step, the system searches the designated JOBLIB, 

PRODUCTA.LOADLIB, for a module with that name. Having not 
found it there, the system then searches the system 
libraries where it is finally found and loaded into the 
computer's memory for execution. 

15 In STEP2, the user has designated that the programs • 

for software product B located in the library 
PRODUCTS. LOADL IB be available for the current job step 
(i.e., STEPLIB). The system is instructed in the STEP2 
EXEC statement to use the program "SORTB" . It begins by 

20 searching PRODUCTS. LOADL IB where it finds the module 

SORTB and loads it into the computer' s memory for 
execution. 

Lastly, in STEP3, the user has not designated a 
STEPLIB and the definition from STEP2 has, so to speak, 

25 expired. The system is instructed in the current EXEC 

statement to use the program "RPORTA" . The JOBLIB 
definition is still in effect, hence, it begins by 
searching PRODUCTA.LOADLIB where it finds that module and 
loaded into the computer's memory for execution, 

30 Upon execution, should a program, such as SORTB, 

request that other modules be loaded and subsequently 
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executed, the operating system conducts a search using 
the very same search order as that used to load SORTB 
(i.e., in STEP2) to load the desired modules into the 
computer's memory for execution. 
5 The present invention determines the identity and 

order of the load libraries used by a particular process 
by reading the JCL data structures of the current job to 
obtain the load library list for the process, or by 
referring to equivalent in- storage data created from the 

10 JCL by the operating system, such as in OS/3 90, the Task 

Input Output Table (TIOT) . Optionally, the Monitor stores 
this data in a library selection table for processing by 
other programs. 

Figure 5 shows the foregoing and additional detail 

15 steps associated with determining module names, steps 

(90-102) and locating a module for a load link (steps 
104-116) . 

Referring to Figure 7, the Monitor proceeds to 
locate the load library from which the module was 

20 accessed using the same search order of precedence as 

used by the operating system. Reading the appropriate 
list of selected load libraries, such as contained in the 
TIOT, the Monitor determines which physical load 
libraries have been associated with the current STEPLIB 

25 and JOBLIB, if any. For each module located in the LMT, 

the Monitor searches for a module with that name in the 
physical library defined as the STEPLIB- If that module 
has not been found or a STEPLIB is not defined, the 
Monitor performs the same process for the physical 

30 library named as the JOBLIB. Similarly, if the module is 

not in JOBLIB or a JOBLIB is not defined, the Monitor 
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performs the repeats the process in turn, and in the same 
order as the operating system, for each of the system 
libraries until found. 

The search ends with the first physical library 
5 found to contain that module. If the results are 

inconclusive, or as an added measure of confidence, the 
module characteristics, such as size and date, can also 
be matched against those of the module found in the 
physical library. 

10 The entry in the module usage table is augmented to 

include the physical name of the libra2ry in which the 
module was found and those results are stored for 
processing and interpretation by another program. 

The process is repeated until all modules have been 

15 processed, as shown in the detailed steps 120-144 in 

Figure 7 , 

Although the present invention has been described in 
relation to particular embodiments thereof, many other 
variations and modifications and other uses will become 
20 apparent to those skilled in the art. It is preferred, 

therefore, that the present invention be limited not by 
the specific disclosure herein, but only by the appended 
claims . 
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WHAT 15 CLAIMED IS : 

1. A system for determining program usage on a 
computer, the system comprising: 

a plurality of executable software programs 
constituting software products, each of the software 
products being constituted of one or more load modules, 
the load modules being stored in at least one memory of 
the computer; 

an operating system of the computer that controls 
execution in the computer of the software products 
through the invocation of respective load modules 
thereof ; 

a monitor that is periodically triggered to collect 
load module execution information; 

a correlator that correlates the load module 
execution information with data that associates load 
module names with corresponding software products and 
develops a list of software products executed in the 
computer over the course of a given time period; and 

a reporter that outputs data reflecting the use of 
the software products in the computer in terms of 
software product names thereof . 

2. The system of claim 1, in which the monitor 
operates by taking periodic snapshots of the then current 
state of active processes in the computer. 

3. The system of claim 2, including a facility 
that allows adjusting the period between snapshots in 
response to program usage activity levels. 
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4. The system of claim 2, in which the monitor 
produces a list of executing load modules and their 
respective directory path names. 

5. The system of claim 2, including a facility 
that determines how many processes have begun and ended 
between snapshots. 

6. The system of claim 2, including a facility 
that compares successive snapshots to determine which 
modules have executed and how many were missed. 

7. The system of claim 1, in which the correlator 
operates in conjunction with a knowledge base that 
associates load module names with software product names. 

8. The system of claim 1, further including a 
surveying program that develops an inventory of 
substantially all software products on the computer and a 
facility which produces a list of non-used software 
products based on comparing the inventory of software 
products against the data output ted by the reporter which 
reflects the use of the software products in the 
computer. 

9. The system of claim 11, in which the knowledge 
base is a database of records which also associates file 
names to software products that use them and additionally 
includes at least one of the following: flags indicating 
if a module is used loniquely or shared among vendor 
products; a number indicating file matches required for 
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correlation with the product; file type; file size; file 
creation date; and embedded strings of text. 

10. The system of claim 1, in which the monitor 
collects load module execution information by deducing 
which load modules are being used in given processes of 
the computer, without directly monitoring the actual 
invocation by the operating system of the load modules . 

11. The system of claim 10, in which the monitor 
obtains the load module execution information from a load 
module table created by the operating system which makes 
entries in the load module tables as processes are 
executed and access requests for load modules are made. 

12. The system of claim 10, in which the monitor is 
implemented to execute every time the end of a process is 
reached. 

13. The system of claim 10, in which the monitor 
executes as an exit routine near the end of a process . 

14. The system of claim 10, in which the monitor 
gathers and accumulates usage data across sub processes 
of a higher level process so that when the load module 
table is successively read, only those module entries not 
previously encountered in a prior sub process of the 
current high level process are accumulated and names of 
load modules already found in the table for the current 
high level process are ignored. 
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15. The system of claim 10, in which the correlator 
operates by identifying the names of all software 
products used by correlating module usage data by using a 
knowledge base that associates the names of load modules 
with software products they comprise. 

16. The system of claim 10, in which the correlator 
operates by correlating module usage data with an 
inventory of software products that itself has been 
obtained by correlating in a knowledge base load module 
names with software product names. 

17. The system of claim 1, in which the monitor 
collects software product execution information by 
monitoring input or output to specific files or datasets 
by the software products, wherein such inputs and outputs 
are associated with corresponding software products or 
groups of software products. 

18. A system for determining program usage on a 
computer, the system comprising: 

a plurality of executable software programs 
constituting software products, each of the software 
products being constituted of one or more load modules, 
the load modules being stored in at least one memory of 
the computer; 

an operating system of the computer that controls 
execution in the computer of software products through 
the invocation of respective load modules thereof; 
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a monitor that collects load module execution 
information reflecting the usage of software products on 
the computer; 

a library source determination facility that 
determines the load library from which each executed load 
module has been loaded; and 

a reporter that outputs data showing the directory 
paths for load modules that have been executed. 

19. The system of claim 11, in which the library 
source determination facility obtains a list of modules 
that have been used by a particular process, deternnaines 
the load libraries and their search order used by the 
process, and using a search order deteannined in a prior 
step, searches the load libraries of the computer for a 
first library containing the same modules that best 
matches the list of modules used. 

20. The system of claim 17, in which the library 
source determination facility uses a JCL (Job Control 
Language) interpreter . 

21. The system of claim 17, in which the load 
library determination facility determines both the 
identity and order of load libraries used by a particular 
process by reading JCL data structures of a current job 
to obtain a load library list for the process- 
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